• 目錄
  • @ Introduce K8s service - Kube-proxy @
  • Introduce K8s service - 4 ways to apply service（1）
  • Introduce K8s service - 4 ways to apply service（2）
  • Service Comparison & Introduce Ingress
  • How to install Traefik
  • Service Debugging

承襲昨天講完的Helm，今天要來看看Service到底是如何把你的服務公開到Cluster之外囉！

為什麼要使用service?

在K8s中，所有的Pods隨時處於變動狀態，隨著replicas的變動，或者服務的rolling update, 一個Pods的IP也會跟著變動，那麼Pods之間要如何找到彼此呢？

services這個抽象概念就這麼誕生了。

運作原理

Service在被創建的時候， Service的Informer會透過Kubernetes Watch API得知有一個Service被創建, 然後kube-proxy這個component便會在Nodes上創建一條新的iptable rule。

iptables是什麼？

可以先看看這篇維基百科認識一下iptables, iptables有四張表

• filter表： 用於過濾封包，iptables指令預設會顯示這張表
• nat表： 用於位址轉換（snat, dnat）, 要了解詳細定義可以看這
• mangle表: 用於處理封包
• raw表： 用於處理異常

每當有服務被創建時， kube-proxy就會新增rules到filter & nat這兩張表。

如何確認kube-proxy是否真的有將rules加到nodes?

先透過

kubectl get service

看看先前創建的Service:

然後進入其中一台Node，輸入

sudo iptables-save

就可以看到有相對應的rules被創建

基本上查過每張表之後，會發現Kube-proxy只會改到filter & nat這兩張表

輸入

sudo iptables -L -t filter

可以看到

這是異常的服務，前一篇有提到如果沒有endpoint，這個cluster IP是ping不到的

這種才是正常的。

輸入

sudo iptables -L -t nat

可以看到更多資訊：

這張是node port模式有的chain

取其中一個target "KUBE-SVC-7JGDB7JIEYQ4DQWR" 在log裡翻找

可以看到他對應到的name space, 以及在cluster & node上expose出的port

再繼續找還可以看到這個target的三個rules被選中的概率
這裡之所以會有三條，跟deployments的replicas數量設置有關

可以看到第一條規則是 1/3
第二條規則被選中的機率是 2/3 * 1/2 = 1/3
最後一條規則被選中的機率則是 1 - (1/3 + 1/3) = 1/3

為什麼要這樣設置呢？

因為iptables的rules是由上而下執行的，為了確保在隨機的模式下三條規則被選中的機率都是相同的，機率才這樣設計。

接下來會談談Service的四種Types。

Reference

1. Kubernetes Informer: https://www.kubernetes.org.cn/2693.html
2. 小信豬的原始部落 - service overview: https://godleon.github.io/blog/Kubernetes/k8s-Service-Overview/
3. iptables： https://www.lijiaocn.com/%E9%A1%B9%E7%9B%AE/2017/03/27/Kubernetes-kube-proxy.html
4. 維基百科 iptables： https://zh.wikipedia.org/wiki/Iptables
5. NAT的兩種模式： https://blog.csdn.net/lasoup/article/details/78289735